RAC集群搭建ASM和私网网卡问题分析 | 过程悲催幸好结局圆满
作者：包雷，数据库主管，擅长oracle mysql组建搭建、故障处理、sql优化，专精高可用方案。
一、项目背景
此项目所有主机资源、网络环境、存储资源都是由XX方提供，都是在云上资源的划分，本文分析XX方一系列问题导致搭建集群失败，后续经过调整，集群成功搭建的过程。
在搭建前的准备和搭建中一共遇到了两个很重要的问题，在此分享给大家，以后如果有需要搭建集群环境的项目应该注意。
单块ASM磁盘不能超过2T大小，即裸LUN的分配要注意不超过2T
私网网卡在虚机上配置不要加地址绑定限制和HAIP的相关问题
二、ASM磁盘的BUG
刚到项目，进行环境检查时发现两个节点挂载的是一块15T的裸LUN，就想到了去年搭建某市教育云时遇到的ASM磁盘组的BUG，这些细节地方确实前期很容易被忽视。
早期的集群是通过各存储厂家的存储技术实现的，直到10G之后，oracle公司研究出ASM磁盘的技术，将集群技术进行统一。
ASM是一个卷管理器，Oracle数据库文件的一个文件系统，ASM支持单实例和集群配置，它是oracle推荐的存储方案，为传统卷管理器，文件系统，裸设备提供一个选择。
2.1 每块ASM磁盘不大于2T
ASM磁盘有一定限制：单块ASM的磁盘不能大于2T，不然创建磁盘组就会报错ORA-15196 WITH ASM DISKS LARGER THAN 2TB。
联系XX云平台的相关人员进行处理，其反馈了两个问题：
- 15T裸LUN得重新划分需要先将其格式化，15T大小的磁盘格式化时间大约8个小时；
- 15T的裸LUN要划分成每块盘不大于2T，至少需要7个LUN来进行划分，但是目前的云平台是不支持划分这么多数量的，无法保证云平台的稳定。
由于ASM磁盘的限制问题，和XX方表示，LUN的重新划分必须要进行，后进行沟通，按照我们提出的需求XX方进行处理，但是由于前期对资源没沟通到位，确实对项目的推进效率造成了一定的影响。
2.2 ASM - Scalability and Limits
参考MOS文档：文档 ID 370921.1
ASM磁盘共有如下一些限制：
1、 63 disk groups in a storage system
代表一个存储系统最多只能有63各磁盘组，但是一般我们只需要3到四个磁盘组即可：CRS、ARCH、DATA。
2、 10,000 ASM disks in a storage system
代表一个存储系统最多1万个ASM盘文件，假设我们单块磁盘2T，那我们有2*10000=2万T的空间，这已经很大了，绰绰有余。
3、 2 terabyte maximum storage for each ASM disk
即上文提到的每个ASM磁盘不超过2T，代表我们在挂裸LUN的时候，单个lUN要注意大小。
4、 1 million files for each disk group
代表每个磁盘组最多100万个文件
5、 2.4 terabyte maximum storage for each file
每个文件的最大存储容量2.4T,参考一下即可，我们单块磁盘都不超过2T，没意义的限制。
当然，以上限制到12.1版本之后有所更改，比如只能有63个磁盘组增加到511个，2T磁盘限制也有所修改，具体可以参考文档 ID 370921.1。
三、私网网卡相关问题
在安装Grid集群时候，有一步要在两个节点分别执行root.sh，类似的操作如果有安装过数据库的小伙伴也应该有经历过。那在Grid安装的这一步会出现各种莫名奇妙的问题，这个时候就需要有查看日志进行解决的能力了。、
3.1 私网网卡上绑定的HAIP无法通信
在一节点上执行root.sh成功后，在二节点执行root.sh时报错，截取了oraagent_grid.log一段最初的报错信息，除此之后没有其他的报错信息：
截取的这一段日志比较重要，可以看到第一行开始InstAgent，然后进行clsdmc_respget检查（对此我的理解是两个节点上私网网卡绑定的HAIP进行通信检查），可以看出多次通信未成功，然后报错ORA-03113: end-of-file on communication channel，直接把和ASM信息的数据库断开，然后开始清除InstAgent的信息，至此节点2执行root.sh失败，意味着集群搭建失败。
对于这个错误我的初步判断是XX分配的私网网卡有问题。
和XX方负责人沟通后，并未得到想要的答案，其表示正常的私网网卡，使用没有问题。
没办法，只能去找确凿的证据，来告诉XX方其私网网卡确实有问题。
经过一天的排查下来，最终在MOS文档上 Doc ID 1383737.1 找到证据。
3.1.1 Symptoms
如果这个问题出现在安装Grid Infrastructure执行root.sh脚本时，表现出以下症状：
- root script screen output
$GRID_HOME/cfgtoollogs/crsconfig/rootcrs_<nodename>.log
For 12.1.0.2, the root.sh on the 2nd node could report:
可以看出我们正好符合症状1，执行root.sh脚本出现ORA-03113: end-of-file on communication channel错误。
3.1.2 Details
**case 1:link local IP (169.254.x.x) is being used by other adapter/network **
169.254.X.X这个IP时执行root.sh脚本时候，会自动绑定一个HAIP的信息到私网网卡上，如果这个IP正好被其他设备占用，那当然会绑定失败，最简单的检查办法是通过ifconfig -a进行检查是否存在169.254.X.X相关信息。Case2: firewall exists between nodes on private network (iptables etc)
两节点之间的private network之间存在防火墙等问题，比如iptables,ipmon等等。HAIP is up on some nodes but not on all
HAIP只在一个节点上绑定了，但是并不是所有节点都绑定了HAIP，在两个节点都进行ifconfig检查，就会发现eth1网卡（私有网卡）下面多了一个169.254.X.X格式的HAIPCase4: HAIP is up on all nodes but some do not have route info
虽然所有节点上都有HAIP的信息，但是路由表上没有相关信息。
检查路由表，发现两个节点都是有对应的路由信息，应该也不是这个问题Case5. HAIP is up on all nodes and route info is presented but HAIP is not pingable 虽然HAIP在每个节点上都有绑定，而且路由表上也有对应IP信息，但是无法ping通。
在项目现场，用两个16.254.X.X的IP进行互相ping，发现两个IP无法ping通，于是将此问题和XX方沟通，告知其肯定是私网的问题，希望其进行排查，最终XX方给了回复，确实是私网出现了问题。
由于拿出了十足的证据告诉XX方确实是他们方面出现了问题，所以后面问题的解决也比较快。
这儿告诉XX方问题确实出现了eth1这个网卡上。
原来XX方面做了对应网卡的地址绑定，每块网卡写死IP就只有对应IP能通信，坑...
3.2 root.sh Fails to Start HAIP as Default Gateway is Configured for Private Network VLAN
参考文档 ID 1366211.1
在XX方将对应地址绑定配置修改掉后，重新搭建集群，每次重新搭建集群就得将所有文件删掉，将存储dd清空，非常麻烦。
本以为这次应该可以大功告成了，没想到跑一节点的root.sh就直接报错，真是尴尬和烦！
报错信息：
这次有了私网的经验，直接检查HAIP，发现根本没有绑定HAIP，于是直接将情况和XX方进行沟通，XX方应该也意识到时自己的问题，这次对方配合很迅速。
告知XX方，eth1网卡无法绑定IP信息
原来问题是由于他们CAS配置只改了一半，没改完全，导致无法绑定IP信息，真是坑...
四、总结
还好，最后将集群搭建的事宜圆满完成了。
简单总结下吧：
1.ASM磁盘不能大于2T在项目上以后很常见吧，现在存储空间都很大，动辄就是申请15T的资源，那么前期沟通，应该就要知晓裸LUN不能大于2T，免得15T又只划分一个LUN，重新格式化需要很长时间；
2.项目上有其他厂家进行配合时候，有事情一定要给他拿出证据，告诉他哪里哪里有问题，厂家很多都是提交工单，然后进行处理模式，这种固化的模式导致你告诉他可能哪里哪里有问题，他们根本不会分析的，你必须，必须告诉他你们这个地方确实有问题，他们才会进行处理；
3.心态的问题,考虑到后期还要和XX方一直合作，克制，克制，克制……
原文地址：http://www.aixchina.net/Article/178531
长按二维码关注“AIX专家俱乐部”公众号